Skip to content

Add .github/copilot-instructions.md for Copilot coding agent#157

Open
kaminer wants to merge 2 commits intomasterfrom
add-copilot-instructions
Open

Add .github/copilot-instructions.md for Copilot coding agent#157
kaminer wants to merge 2 commits intomasterfrom
add-copilot-instructions

Conversation

@kaminer
Copy link
Copy Markdown
Contributor

@kaminer kaminer commented Apr 4, 2026

Summary

Adds a .github/copilot-instructions.md file so the GitHub Copilot coding agent can work autonomously on this repo with full project context.

What it covers

  • Project architecture: class hierarchy (Matrix -> NumericMatrix/SymbolicMatrix), dispatch logic, FLINT backend
  • Code conventions: testing patterns (*_test.py, pytest-benchmark), numeric precision rules (no Python float), naming style
  • Benchmark rules: pytest-only, no standalone scripts, test through public Matrix API
  • PR review workflow: read comments -> minimal fix -> run tests -> clear commit messages
  • Reviewer preferences: specific patterns from RotemKalisch (documented from PR perf: binary splitting for NumericMatrix.walk() #156 review rounds)

Why

Enables the Copilot coding agent to handle PR review comments, issue assignments, and code changes while following the team's established conventions.

How to enable

A repo admin needs to go to Settings -> Copilot -> Coding agent and toggle it on. Then use @copilot in any PR comment or issue to invoke it with these instructions loaded.

kaminer added 2 commits April 4, 2026 22:48
Documents project architecture, code conventions, testing patterns,
reviewer preferences, and PR review workflow so that the Copilot
coding agent can handle review comments autonomously.
- Add style rule: no decorative section separators or redundant comments
- Add testing rule: use @pytest.mark.parametrize for variations
- Both learned from RotemKalisch's review feedback on PR #156
- `ramanujantools/flint_core/symbolic_matrix.py` — `SymbolicMatrix`.
- `Matrix.walk()` dispatches to `NumericMatrix.walk()` or `SymbolicMatrix.walk()` based on input type.
- `@batched` decorator (`ramanujantools/utils/batched.py`) allows `iterations` to be scalar or list.
- `NumericMatrix.lambda_from_rt()` compiles a SymPy matrix into a fast FLINT evaluator.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Too specific

- `Matrix.walk()` dispatches to `NumericMatrix.walk()` or `SymbolicMatrix.walk()` based on input type.
- `@batched` decorator (`ramanujantools/utils/batched.py`) allows `iterations` to be scalar or list.
- `NumericMatrix.lambda_from_rt()` compiles a SymPy matrix into a fast FLINT evaluator.
- `Matrix._walk_inner` has an LRU cache; clear with `Matrix._walk_inner.cache_clear()` before benchmarks.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same, too specific

### Testing
- Tests live next to source as `*_test.py` files (e.g., `numeric_matrix_test.py`).
- Run with `pytest`. Benchmarks use `pytest-benchmark`.
- Benchmarks live in `matrix_benchmark.py` and run **strictly via pytest**, never as standalone scripts.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not only

## Code conventions

### Testing
- Tests live next to source as `*_test.py` files (e.g., `numeric_matrix_test.py`).
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Give matrix_test.py as an example, a more central code example.

### Numeric precision
- **Never use Python `float`** for mathematical verification. Use `mpmath.mpf`, `sympy.Rational`, or FLINT types.
- Set `mpmath.mp.dps` to at least 2× the digits you need.
- Verify formulas to 100+ decimal places.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Kinda arbitrary, I'd remove this

1. Read every review comment carefully before making changes.
2. Prefer the simplest fix that addresses the reviewer's concern.
3. Run the relevant tests after every change (`pytest <test_file> -v`).
4. If the reviewer asks to check for existing utilities/packages, do the research and report findings even if no suitable alternative exists.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

too specific, can remove

3. Run the relevant tests after every change (`pytest <test_file> -v`).
4. If the reviewer asks to check for existing utilities/packages, do the research and report findings even if no suitable alternative exists.
5. Commit with a clear message referencing which review comments are addressed.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add: When resolving a comment, mark it as resolved. When unsure how to proceed, ask in a comment.

## Reviewer preferences (RotemKalisch)

- Benchmarks must be pytest-only — no `if __name__ == "__main__"` standalone scripts.
- Test through the public `Matrix` class API where possible.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove, too specific


- Benchmarks must be pytest-only — no `if __name__ == "__main__"` standalone scripts.
- Test through the public `Matrix` class API where possible.
- Check for existing pythonic utilities/packages before writing custom algorithms.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only if they do not introduce new dependencies. If they do - need to weigh the pros and cons. Should discuss with the user.


## Repository rules

- Do not push to `master` directly. Use feature branches and PRs.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Branch style: x/y where x is feature, bugfix, hotfix, refactororoptimization, and y` is a short description

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants